The Internet was created primarily as a means for establishing point-to-point connections between hosts: It utilised host-to-host applications such as ftp and telnet. The historical origins of the Internet have resulted in it having a focus on hosts and end points as primary named entities, i.e. hosts are identified by URLs and endpoints are identified by IP addresses (although in many cases a host is also an endpoint). This focus creates a number of well known problems. For example, the current inter-networking paradigm provides an open network which is not well suited when some users are selfish and others malicious. There is nothing inherent in the Internet architecture to prevent an attacker flooding an IP address with traffic resulting in the party “owning” that IP address potentially being denied access to the Internet. A further problem is that the Internet does not provide an inherent mechanism for the authentication of data. For example, a user retrieving a web page using an http GET and a published URL has no way of knowing if the retrieved data is authentic.
The Internet has now evolved into a system which is used primarily for data retrieval and service access. Indeed, much of the data accessed over the Internet is static, i.e. it does not change, at least in the short term. Even a dynamic web page is likely to consist of a number of static components that are glued together with a small amount of client-specific (i.e. variable) HTML code. Generalising, it can be argued that, with the possible exception of real-time interactive traffic such as voice calls, the majority of current network traffic is data oriented. The (user) applications making use of the Internet are not interested in creating connections, but rather in transferring well defined pieces of data. Whilst mechanisms such as multicasting and peer-to-peer networks address some of the specific issues, these do not address the fundamental deficiencies present in the Internet.
A network paradigm known as “publish/subscribe” or “pubsub” is being developed and addresses many of these fundamental deficiencies. The paradigm is based upon identifying data within the pubsub network using a publication identifier which is cryptographically bound to the data. The publication identifier may be for example a hash of a private key owned by the publisher of the data. The publisher then attaches to the data a signature taken over the data using the associated private key and publishes the data on the network. The data may be held at a number of different locations. In order to retrieve data, a user sends a Subscribe message containing the publication identifier and his own location, to a local router. The router uses some rendezvous system to locate a copy of the data (typically the closest copy) and routes the Subscribe message to that location. Within an autonomous system, e.g. a network owned by a single operator, the rendezvous system may comprise a single rendezvous server that maintains a mapping between publication identities and data locations. A copy of the data with signature and public key is delivered to the requesting user via some optimised route. The user does not necessarily know or care from which location the data is retrieved. Moreover, the pubsub network does not require a separate DNS lookup to be performed in order to resolve a URL into an IP address. Rather, the Subscribe message acts both as source locator and data request.
Within a pubsub network, routers will only deliver data in the event that a Subscribe message has been received from a destination. Flooding attacks which result in a denial of service are thereby effectively prevented.
It is likely that in the short to medium term pubsub networks will be established as standalone networks, i.e. “islands”, which use gateways to connect to the Internet. It can be envisaged that a user attached to one pubsub island will want to retrieve data from another pubsub island via the Internet (or possibly another IP network). In this case, the user might send a Subscribe message to a local router and which contains a publication identity for the data. Assuming that the router is appropriately configured, it may recognise that the publication identity is not a local identity, and will forward it to the Internet gateway. The present DNS system does not however provide any means to perform a reverse mapping between a publication identity and an IP address of a remote node, in this case a location at which the requested data is held.